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COMPUTER PROCESS RESOURCE MODELLING 
METHOD AND APPARATUS 



REFERENCE to APPEEPIX h 

Appendix A, which is a part of this disclosure, is 
a list of computer programs and related data in one 

10 embodiment of the present invention, which is described 
more completely below. 

A portion of the disclosure of this patent 
document contains material which is subject to 
copyright protection. The copyright owner has no 

15 objection to the facsimile reproduction by anyone of 
the patent document or the patent disclosure, as it 
appears in the Patent and Trademark Office patent files 
or records, but otherwise reserves all copyright rights 
whatsoever. 

20 

BACKGROUND OF THE INVENTION 
FteM of the Invention 

The present invention relates to the analysis of 
computer programs and, in particular, to the detection 
25 of programming errors in a computer program through 
analysis of the use of resources prescribed by the 
computer program. 

Discussion of Related Art 

30 Some existing programming error detection methods 

detect, violations in the computer instruction protocol 
with which a particular program comports. Such a 
programming error detection method is called "static 
checking 91 since the syntax of the computer 

35 instructions, or "statements", of the computer program 
is analyzed outside the context of the behavior 
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resulting from the execution of those statements. The 
term "statement" is used herein as it is defined in 
Section 6.6 of American N ational Standard for 
Programming Languages -?-C (American National Standards 
5 Institute/ International Organization for 

Standardization ANSI/ISO 9899-1990) , which is 
reproduced in Herbert Schildt, The AnnatatSd ANSI C 
Standard . (Osborne McGraw-Hill 1990) (hereinafter the C 
Standard) . Briefly, in the context of the C computer 

10 language, a statement is a computer instruction other 
than a declaration. In other words, a statement is a 
any expression or instruction which directs a computer 
to carry out one or more processing steps. Static 
checking in the context of the C computer language 

15 includes, for example, (i) making 6ure that no two 

variables in the computer program are identified by the 
same name; (ii) ensuring that each "break H statement 
corresponds to a preceding "while", "for", or "switch" 
statement; and (iii) verifying that operators are 

20 applied to compatible operands. Static checking is 
discussed, for example, in Alfred V. Aho et al., 
Compilers. (Addison Wesley 1988) . 

Some existing static checking methods, which are 
generally called "data flow analysis" techniques, 

25 analyze data flow through a program to detect 

programming errors* Such analysis includes use of 
control flow information, such as sequencing of 
statements and loop statements, to detect the improper 
use of data objects, e.g., the use of a variable before 

30 a value has been assigned to the variable. Flow of 
control in a computer program is the particular 
sequence in which computer instructions of the computer 
program are executed in a computer process defined by 
the computer program. Computer programs and processes 

35 and the relation therebetween are discussed more 

completely below. Data flow techniques are discussed 
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in Beizer # Software T esting Techniques. (1990) at pp. 
145-172. 

Existing static checking techniques suffer from 
the inability to track use of resources through several 
5 discrete components of a computer program such as 

several functions which collectively form a computer 
program. For example , a variable may be initialized in 
a first function and used in a calculation in a second, 
subsequently executed function. By analysis of only 

10 the computer instructions of the second function, the 
variable appears to be used before the variable is 
initialized which can be erroneously reported as an 
error. In addition, existing static checking 
techniques are static in nature and do not consider 

15 particular data values associates with particular data 
objects. Static analysis is limited to what can be 
determined without considering the dynamic effects of 
program execution. Beizer describes several areas for 
which static analysis is inadequate, including: arrays, 

20 especially dynamically calculated indices and 

dynamically allocated arrays; records and pointers; 
files; and alternate state tables, representing the 
different semantics of different types in the same 
program. 

25 Static checkers do not detect errors involving 

calculated addresses corresponding to dynamically 
allocated memory or calculated indices into arrays. 
Calculated addresses and indices are addresses and 
indices, respectively, which are calculated during the 

30 execution of a computer process. Static checkers do 
not detect such errors in a computer program because 
checking for such errors typically involves determining 
the precise values of calculated addresses and indices, 
which in turn involves consideration of the behavior of 

35 the computer program during execution, i.e., as a 
computer process. 
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Static checkers do not detect errors involving the 
use of questionably allocated resources or the use of 
resources whose state is determined by the value of a 
variable or other data object. In the C computer 
5 language, a resource, e.g., dynamically allocate memory 
or a file, is questionably allocated. In other words, 
a function which allocates the resource completes 
successfully, even if allocation of the resource 
failed. Whether the allocation succeeded is determined 

10 by comparison of the returned item of the function, 
which is a pointer to the allocated resource, to an 
invalid value, e.g., NULL. Static checkers do not 
consider the behavior of a called function but instead 
only verify that the syntax of the call to the called 

15 function comports with the syntax prescribed in the 
particular computer language. Therefore, static 
checkers do not detect errors involving use of a 
resource which is questionably allocated. 

As described above, a static checker does not 

20 consider the behavior of a called function. Thus, 

verifying the use of a resource which spans multiple 
functions is impossible. For example, if a first 
function allocates a resource, a second function uses 
the resource, and a third function deallocates the 

25 resource, static checking of any of the first, second, 
and third functions alone or a function calling all 
three functions, cannot verify the proper use of the 
resource. 

When using an error detection technique, which 
30 employs insufficient information regarding the behavior 
of a computer program during execution f the errors 
reported by such a technique are either under - inclusive 
or over-inclusive. For example, if a function accepts 
as a parameter a pointer to an allocated resource, 
35 e.g., a file, and uses the parameter without comparing 
the parameter to an invalid pointer, the function 
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contains a possible error. Whether the function 
contains an error depends on circumstances which are 
unknown within the context of the function. For 
example, if the pointer is verified to be a valid 
5 pointer before the function is called, there is no 
error in the function. To report the use of the 
pointer as an error would clutter an analysis of the 
function with a falsely reported error, and thus would 
be over-inclusive. Falsely reporting errors in 

10 analysis of a large program, at best, is an 

inconvenience to a program developer and, at worst, 
renders analysis of a computer program useless. If the 
pointer is not checked to be valid prior to calling the 
function, failure to report the error results in 

15 failure to detect an error which can cause an execution 
of the computer program to be aborted abruptly and can 
result in the corruption of data structures and 
possibly in the loss of valuable data. 

One particular drawback of the failure of static 

20 checking techniques to consider the dynamic behavior of 
a computer program is the reporting of apparent, but 
"false", errors, i.e., errojrs resulting from computer 
instructions through which control cannot flow. In 
functions in which control flow paths depend on 

25 particular values associated with particular data 

structures and program variables, control flow cannot 
be determined without considering the values associated 
with those data structures and variables which 
generally in turn cannot be determined without 

30 consideration of the behavior of the function during 
execution. As a result, instructions which are not 
executed or which are executed only under specific 
circumstances are generally assumed to always be 
executed by static checkers. 

35 Another type of existing programming error 

detection technique is called program verification. In 
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program verification , a computer program is treated as 
a formal mathematical object. Errors in the computer 
program are detecting by proving, or failing to prove, 
certain properties of the computer program using 
5 theoretical mathematics. One property for which a 
proof is generally attempted is that, given certain 
inputs, a computer process defined by the computer 
program produces certain outputs. If the proof fails, 
the computer program contains a programming error. 

10 Such program verification techniques are described, for 
example, in Eric C.R. Hehner et al., A Practical Theory 
of Procrr flMniVTr (Verlag 1993) and Ole-Johan Dahl, 
Verifiable Programming , (Prentice Hall 1992). 

Verified programming techniques are limited in at 

15 least two ways: (i) only properties of computer 
programs which can be expressed and automatically 
proven using formal logic can be verified, and (ii) a 
person developing a computer program generally must 
formally specify the properties of the computer 

20 program. Formally specifying the properties of a 

computer program is extremely difficult in any case and 
intractable for larger programs. As a result, 
commercially successful products employing verified 
programming techniques are quite rare. 

25 In another type of programming error detection 

technique, a computer program is executed, thus forming 
a computer process, and the behavior of the computer 
process is monitored. Since a computer program is 
analyzed during execution, such a programming error 

30 detection technique is called "runtime checking 19 . Some 
runtime checking techniques include automatically 
inserting computer instructions into a computer program 
such that execution of the inserted computer 
instructions note, during execution of the computer 

35 program, the status of variables and resources of the 
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computer program. Such an error detection technique is 
described by U.S. Patent Number 5, 193,180 to Hastings. 

Runtime checking can typically detect errors such 
as array indices out of bounds and memory lea)cs. 
5 Examples of runtime checking include Purify which is 
available from Pure Software Inc. of Sunnyvale, 
California and Insight which is available from Parasoft 
Corporation of Pasadena, California. Purify inserts 
into a computer program monitoring computer 

10 instructions after a computer program has been compiled 
in to an object code form, and Insight inserts into a 
computer program monitoring computer instructions 
before a computer program is compiled, i.e., while the 
computer program is still in a source code form. 

15 Runtime checking is generally limited to what can 

be determined by actually executing the computer 
instructions of a computer program with actual, 
specific inputs. Runtime checking does not consider 
all possible control flow paths through a computer 

20 program but considers only those control flow paths 

corresponding to the particular inputs to the computer 
program supplied during execution. It is generally 
impracticable to coerce a computer process, formed by 
execution of the computer instructions of a computer 

25 program, to follow all possible control flow paths. To 
do so requires that a programmer anticipate all 
possible contingencies which might occur during 
execution of the computer instructions of a computer 
program and to cause or emulate all possible 

30 combinations of occurrences of such contingencies. 

Furthermore, runtime checking can only be used 
when the computer program is complete. Analysis of a 
single function before the function is incorporated 
into a complete program is impossible in runtime 

35 checking since the function must be executed to be 
analyzed. Analysis of a function using runtime 
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checking therefore requires that (i) all functions of a 
computer program be developed and combined to form the 
computer program prior to analysis of any of the 
functions or (ii) that, a special purpose test program, 
5 which incorporates the function, be developed to test 
the function. Top-down programming, which involves the 
design, implementation, and testing of individual 
functions prior to inclusion in a complete computer 
program and which is a widely known and preferred 
10 method of developing more complex computer programs, 
therefore does not lend itself well to runtime 
analysis. 

What is needed is a programming error detection 
technique which considers the dynamic behavior of a 

15 computer program, which automatically considers 

substantially all possible control flow paths through 
the computer program, and which does not require a 
programmer of such a computer program to express the 
computer program in an alternative, e.g., mathematical, 

20 form. What is further needed is a programming error 
detection technique which analyzes an individual 
component of a program, considering the behavior of the 
component during execution. What is further needed is 
a programming error detection technique which considers 

25 the behavior of a component whose execution is invoked 
by a computer program component under analysis. 

SUMMARY OF THE INVENTION 

In accordance with the present invention, a 
30 computer program is analyzed, and programming errors in 
the computer program are detected, by modelling the 
behavior of resources used by the computer program and 
detecting potential state violations in the those 
resources. A resource is modelled according to 
35 resource states and resource state transitions which 
describe the behavior of the resource. The computer 
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instructions of the computer program are dynamically 
inspected, i.e., the dynamic behavior of the computer 
instructions is determined and the states of resources 
are changed according to the dynamic behavior of the 
5 computer instructions. 

Each component of a computer program is analyzed 
individually. Use of a resource whose use spans more 
than one component, e.g., a resource which is allocated 
by a first component, used by a second component and 

10 deallocated by a third component, is analyzed by 
modelling the externals of each component. Two 
components of a computer program communicate with one 
another through the externals of each component. For 
example, information regarding a resource allocated by 

15 a first component is transmitted to a second component, 
which uses the resource, through the externals of the 
first and second components. By analyzing the behavior 
of each component with respect to the externals of the 
component, resources whose use span more than one 

20 component are properly modelled. 

Each component is analyzed and the effect of 
execution of the component. on each external of the 
component is determined. From the analysis of the 
component, a model of the component is created. The 

25 model of the component describes the effect of 

execution of the component on each external of the 
component in terms of changes in the respective states 
of the externals and the introduction of new resources 
associated with any external of the -component. 

30 Execution of the modelled component can have any of a 

number of effects on any individual external, and those 
effects are represented in a composite state of the 
external. The model of the component can then be used 
in the analysis of other components which invoke 

35 execution of the modelled component. 
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